home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1737 < prev    next >
Text File  |  1995-07-25  |  16KB  |  396 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         K. Sollins
  8. Request for Comments: 1737                                       MIT/LCS
  9. Category: Informational                                      L. Masinter
  10.                                                        Xerox Corporation
  11.                                                            December 1994
  12.  
  13.  
  14.            Functional Requirements for Uniform Resource Names
  15.  
  16. Status of this Memo
  17.  
  18.    This memo provides information for the Internet community.  This memo
  19.    does not specify an Internet standard of any kind.  Distribution of
  20.    this memo is unlimited.
  21.  
  22. 1.  Introduction
  23.  
  24.    This document specifies a minimum set of requirements for a kind of
  25.    Internet resource identifier known as Uniform Resource Names (URNs).
  26.    URNs fit within a larger Internet information architecture, which in
  27.    turn is composed of, additionally, Uniform Resource Characteristics
  28.    (URCs), and Uniform Resource Locators (URLs).  URNs are used for
  29.    identification, URCs for including meta-information, and URLs for
  30.    locating or finding resources.  It is provided as a basis for
  31.    evaluating standards for URNs.  The discussions of this work have
  32.    occurred on the mailing list uri@bunyip.com and at the URI Working
  33.    Group sessions of the IETF.
  34.  
  35.    The requirements described here are not necessarily exhaustive; for
  36.    example, there are several issues dealing with support for
  37.    replication of resources and with security that have been discussed;
  38.    however, the problems are not well enough understood at this time to
  39.    include specific requirements in those areas here.
  40.  
  41.    Within the general area of distributed object systems design, there
  42.    are many concepts and designs that are discussed under the general
  43.    topic of "naming". The URN requirements here are for a facility that
  44.    addresses a different (and, in general, more stringent) set of needs
  45.    than are frequently the domain of general object naming.
  46.  
  47.    The requirements for Uniform Resource Names fit within the overall
  48.    architecture of Uniform Resource Identification.  In order to build
  49.    applications in the most general case, the user must be able to
  50.    discover and identify the information, objects, or what we will call
  51.    in this architecture resources, on which the application is to
  52.    operate.  Beyond this statement, the URI architecture does not define
  53.    "resource."  As the network and interconnectivity grow, the ability
  54.    to make use of remote, perhaps independently managed, resources will
  55.  
  56.  
  57.  
  58. Sollins & Masinter                                              [Page 1]
  59.  
  60. RFC 1737        Requirements for Uniform Resource Names    December 1994
  61.  
  62.  
  63.    become more and more important.  This activity of discovering and
  64.    utilizing resources can be broken down into those activities where
  65.    one of the primary constraints is human utility and facility and
  66.    those in which human involvement is small or nonexistent.  Human
  67.    naming must have such characteristics as being both mnemonic and
  68.    short.  Humans, in contrast with computers, are good at heuristic
  69.    disambiguation and wide variability in structure.  In order for
  70.    computer and network based systems to support global naming and
  71.    access to resources that have perhaps an indeterminate lifetime, the
  72.    flexibility and attendant unreliability of human-friendly names
  73.    should be translated into a naming infrastructure more appropriate
  74.    for the underlying support system.  It is this underlying support
  75.    system that the Internet Information Infrastructure Architecture
  76.    (IIIA) is addressing.
  77.  
  78.    Within the IIIA, several sorts of information about resources are
  79.    specified and divided among different sorts of structures, along
  80.    functional lines.  In order to access information, one must be able
  81.    to discover or identify the particular information desired,
  82.    determined both how and where it might be used or accessed.  The
  83.    partitioning of the functionality in this architecture is into
  84.    uniform resource names (URN), uniform resource characteristics (URC),
  85.    and uniform resource locators (URL).  A URN identifies a resource or
  86.    unit of information.  It may identify, for example, intellectual
  87.    content, a particular presentation of intellectual content, or
  88.    whatever a name assignment authority determines is a distinctly
  89.    namable entity.  A URL identifies the location or a container for an
  90.    instance of a resource identified by a URN.  The resource identified
  91.    by a URN may reside in one or more locations at any given time, may
  92.    move, or may not be available at all.  Of course, not all resources
  93.    will move during their lifetimes, and not all resources, although
  94.    identifiable and identified by a URN will be instantiated at any
  95.    given time.  As such a URL is identifying a place where a resource
  96.    may reside, or a container, as distinct from the resource itself
  97.    identified by the URN.  A URC is a set of meta-level information
  98.    about a resource.  Some examples of such meta-information are: owner,
  99.    encoding, access restrictions (perhaps for particular instances),
  100.    cost.
  101.  
  102.    With this in mind, we can make the following statement:
  103.  
  104.    o  The purpose or function of a URN is to provide a globally unique,
  105.       persistent identifier used for recognition, for access to
  106.       characteristics of the resource or for access to the resource
  107.       itself.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Sollins & Masinter                                              [Page 2]
  115.  
  116. RFC 1737        Requirements for Uniform Resource Names    December 1994
  117.  
  118.  
  119.    More specifically, there are two kinds of requirements on URNs:
  120.    requirements on the functional capabilities of URNs, and requirements
  121.    on the way URNs are encoded in data streams and written
  122.    communications.
  123.  
  124. 2. Requirements for functional capabilities
  125.  
  126.    These are the requirements for URNs' functional capabilities:
  127.  
  128.    o Global scope: A URN is a name with global scope which does not
  129.      imply a location.  It has the same meaning everywhere.
  130.  
  131.    o Global uniqueness: The same URN will never be assigned to two
  132.      different resources.
  133.  
  134.    o Persistence: It is intended that the lifetime of a URN be
  135.      permanent.  That is, the URN will be globally unique forever, and
  136.      may well be used as a reference to a resource well beyond the
  137.      lifetime of the resource it identifies or of any naming authority
  138.      involved in the assignment of its name.
  139.  
  140.    o Scalability: URNs can be assigned to any resource that might
  141.      conceivably be available on the network, for hundreds of years.
  142.  
  143.    o Legacy support: The scheme must permit the support of existing
  144.      legacy naming systems, insofar as they satisfy the other
  145.      requirements described here. For example, ISBN numbers, ISO
  146.      public identifiers, and UPC product codes seem to satisfy the
  147.      functional requirements, and allow an embedding that satisfies
  148.      the syntactic requirements described here.
  149.  
  150.    o Extensibility: Any scheme for URNs must permit future extensions to
  151.      the scheme.
  152.  
  153.    o Independence: It is solely the responsibility of a name issuing
  154.      authority to determine the conditions under which it will issue a
  155.      name.
  156.  
  157.    o Resolution: A URN will not impede resolution (translation into a
  158.      URL, q.v.). To be more specific, for URNs that have corresponding
  159.      URLs, there must be some feasible mechanism to translate a URN to a
  160.      URL.
  161.  
  162. 3. Requirements for URN encoding
  163.  
  164.    In addition to requirements on the functional elements of the URNs,
  165.    there are requirements for how they are encoded in a string:
  166.  
  167.  
  168.  
  169.  
  170. Sollins & Masinter                                              [Page 3]
  171.  
  172. RFC 1737        Requirements for Uniform Resource Names    December 1994
  173.  
  174.  
  175.    o Single encoding: The encoding for presentation for people in clear
  176.      text, electronic mail and the like is the same as the encoding in
  177.      other transmissions.
  178.  
  179.    o Simple comparison: A comparison algorithm for URNs is simple,
  180.      local, and deterministic. That is, there is a single algorithm for
  181.      comparing two URNs that does not require contacting any external
  182.      server, is well specified and simple.
  183.  
  184.    o Human transcribability: For URNs to be easily transcribable by
  185.      humans without error, they should be short, use a minimum of
  186.      special characters, and be case insensitive. (There is no strong
  187.      requirement that it be easy for a human to generate or interpret a
  188.      URN; explicit human-accessible semantics of the names is not a
  189.      requirement.)  For this reason, URN comparison is insensitive to
  190.      case, and probably white space and some punctuation marks.
  191.  
  192.    o Transport friendliness: A URN can be transported unmodified in the
  193.      common Internet protocols, such as TCP, SMTP, FTP, Telnet, etc., as
  194.      well as printed paper.
  195.  
  196.    o Machine consumption: A URN can be parsed by a computer.
  197.  
  198.    o Text recognition: The encoding of a URN should enhance the
  199.      ability to find and parse URNs in free text.
  200.  
  201. 4. Implications
  202.  
  203.    For a URN specification to be acceptible, it must meet the previous
  204.    requirements.  We draw a set of conclusions, listed below, from those
  205.    requirements; a specification that satisfies the requirments without
  206.    meetings these conclusions is deemed acceptable, although unlikely to
  207.    occur.
  208.  
  209.    o To satisfy the requirements of uniqueness and scalability, name
  210.      assignment is delegated to naming authorities, who may then assign
  211.      names directly or delegate that authority to sub-authorities.
  212.      Uniqueness is guaranteed by requiring each naming authority to
  213.      guarantee uniqueness.  The names of the naming authorities
  214.      themselves are persistent and globally unique and top level
  215.      authorities will be centrally registered.
  216.  
  217.    o Naming authorities that support scalable naming are encouraged, but
  218.      not required.  Scalability implies that a scheme for devising names
  219.      may be scalable both at its terminators as well as within the
  220.      structure; e.g., in a hierarchical naming scheme, a naming
  221.      authority might have an extensible mechanism for adding new
  222.      sub-registries.
  223.  
  224.  
  225.  
  226. Sollins & Masinter                                              [Page 4]
  227.  
  228. RFC 1737        Requirements for Uniform Resource Names    December 1994
  229.  
  230.  
  231.    o It is strongly recommended that there be a mapping between the
  232.      names generated by each naming authority and URLs.  At any specific
  233.      time there will be zero or more URLs into which a particular URN
  234.      can be mapped.  The naming authority itself need not provide the
  235.      mapping from URN to URL.
  236.  
  237.    o For URNs to be transcribable and transported in mail, it is
  238.      necessary to limit the character set usable in URNs, although there
  239.      is not yet consensus on what the limit might be.
  240.  
  241.    In assigning names, a name assignment authority must abide by the
  242.    preceding constraints, as well as defining its own criteria for
  243.    determining the necessity or indication of a new name assignment.
  244.  
  245. 5. Other considerations
  246.  
  247.    There are three issues about which this document has intentionally
  248.    not taken a position, because it is believed that these are issues to
  249.    be decided by local determination or other services within an
  250.    information infrastructure.  These issues are equality of resources,
  251.    reflection of visible semantics in a URN, and name resolution.
  252.  
  253.    One of the ways in which naming authorities, the assigners of names,
  254.    may choose to make themselves distinctive is by the algorithms by
  255.    which they distinguish or do not distinguish resources from each
  256.    other.  For example, a publisher may choose to distinguish among
  257.    multiple printings of a book, in which minor spelling and
  258.    typographical mistakes have been made, but a library may prefer not
  259.    to make that distinction.  Furthermore, no one algorithm for testing
  260.    for equality is likely to applicable to all sorts of information.
  261.    For example, an algorithm based on testing the equality of two books
  262.    is unlikely to be useful when testing the equality of two
  263.    spreadsheets.  Thus, although this document requires that any
  264.    particular naming authority use one algorithm for determining whether
  265.    two resources it is comparing are the same or different, each naming
  266.    authority can use a different such algorithm and a naming authority
  267.    may restrict the set of resources it chooses to identify in any way
  268.    at all.
  269.  
  270.    A naming authority will also have some algorithm for actually
  271.    choosing a name within its namespace.  It may have an algorithm that
  272.    actually embeds in some way some knowledge about the resource.  In
  273.    turn, that embedding may or may not be made public, and may or may
  274.    not be visible to potential clients.  For example, an unreflective
  275.    URN, simply provides monotonically increasing serial numbers for
  276.    resources.  This conveys nothing other than the identity determined
  277.    by the equality testing algorithm and an ordering of name assignment
  278.    by this server.  It carries no information about the resource itself.
  279.  
  280.  
  281.  
  282. Sollins & Masinter                                              [Page 5]
  283.  
  284. RFC 1737        Requirements for Uniform Resource Names    December 1994
  285.  
  286.  
  287.    An MD5 of the resource at some point, in and of itself may be
  288.    reflective of its contents, and, in fact, the naming authority may be
  289.    perfectly willing to publish the fact that it is using MD5, but if
  290.    the resource is mutable, it still will be the case that any potential
  291.    client cannot do much with the URN other than check for equality.
  292.    If, in contrast, a URN scheme has much in common with the assignment
  293.    ISBN numbers, the algorithm for assigning them is public and by
  294.    knowing it, given a particular ISBN number, one can learn something
  295.    more about the resource in question.  This full range of
  296.    possibilities is allowed according to this requirements document,
  297.    although it is intended that naming authorities be discouraged from
  298.    making accessible to clients semantic information about the resource,
  299.    on the assumption that that may change with time and therefore it is
  300.    unwise to encourage people in any way to depend on that semantics
  301.    being valid.
  302.  
  303.    Last, this document intentionally does not address the problem of
  304.    name resolution, other than to recommend that for each naming
  305.    authority a name translation mechanism exist.  Naming authorities
  306.    assign names, while resolvers or location services of some sort
  307.    assist or provide URN to URL mapping.  There may be one or many such
  308.    services for the resources named by a particular naming authority.
  309.    It may also be the case that there are generic ones providing service
  310.    for many resources of differing naming authorities.  Some may be
  311.    authoritative and others not.  Some may be highly reliable or highly
  312.    available or highly responsive to updates or highly focussed by other
  313.    criteria such as subject matter.  Of course, it is also possible that
  314.    some naming authorities will also act as resolvers for the resources
  315.    they have named.  This document supports and encourages third party
  316.    and distributed services in this area, and therefore intentionally
  317.    makes no statements about requirements of URNs or naming authorities
  318.    on resolvers.
  319.  
  320. Security Considerations
  321.  
  322.    Applications that require translation from names to locations, and
  323.    the resources themselves may require the resources to be
  324.    authenticated. It seems generally that the information about the
  325.    authentication of either the name or the resource to which it refers
  326.    should be carried by separate information passed along with the URN
  327.    rather than in the URN itself.
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Sollins & Masinter                                              [Page 6]
  339.  
  340. RFC 1737        Requirements for Uniform Resource Names    December 1994
  341.  
  342.  
  343. Authors' Addresses
  344.  
  345.    Larry Masinter
  346.    Xerox Palo Alto Research Center
  347.    3333 Coyote Hill Road
  348.    Palo Alto, CA 94304
  349.  
  350.    Phone: (415) 812-4365
  351.    Fax:   (415) 812-4333
  352.    EMail: masinter@parc.xerox.com
  353.  
  354.  
  355.    Karen Sollins
  356.    MIT Laboratory for Computer Science
  357.    545 Technology Square
  358.    Cambridge, MA 02139
  359.  
  360.    Voice: (617) 253-6006
  361.    Phone: (617) 253-2673
  362.    EMail: sollins@lcs.mit.edu
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Sollins & Masinter                                              [Page 7]
  395.  
  396.